Computer programs often have language level exceptions. A language level exception is a result of an executed statement that is outside an allowed range of results to that statement. An example Java language method “foo” is shown below:                Method        int foo( ) {        int A[ ]=new int[2];        A [3]=3;        }        
In the above example method foo returns an integer value of A from an array. The array includes two elements. Next, a third element from the array is requested. Since the array has only 2 elements, then there is not third element and an exception is returned or thrown. If foo were called by another “caller” method, then the exception would be returned to the caller method because foo, as shown above, does not include any exception handlers.
The above method foo is an example of an implicit exception because the exception is a result of a statement execution that results in an out of range result. Exceptions can also be explicit. An explicit exception is a specific statement to throw an exception as is well known in the art. Below is an example of a Java instruction that throws an explicit exception:                throw new applicationexception( )        
A method is often called by a caller method. An example of a caller method “bar” is shown below:
PC#Caller methodint bar( ) {S1try {S2. . .S3foo( )S4. . .S5} catch (exception x) {S6. . .}}
The PC# is a program counter number. For example at program counter S1, the caller method bar tries several statements in order (some not shown) at program counter S2 through program counter S4. The bar method also includes a list of exception handlers such as at program counter S5. The exception handlers at S6 are used to handle or process the exceptions that result from the S2-S4 statements, such as foo, that are executed by the caller method. If the type of an exception thrown in S2-S4 does not match the exception handlers in S5, then if bar has been called by another method, then bar can throw an exception to the method that called bar (i.e. bar's caller method).
FIG. 1 illustrates a prior art process of processing an exception. First, in block 102, a current method executes a statement S in a current try block. In block 104 the statement S returns or throws an exception. In block 106, the data structure of the entire code is searched to find the location of exception handlers in the current try block. In block 108, the runtime switches to a generic code section for analyzing the data structure of the current try block to determine if the current try block includes any exception handlers. If in block 108, the current try block does include exception handlers, then in block 110 the exception handlers are used to process the exception. In block 140, the runtime uses more generic code to analyze the exception handlers to determine if a correct exception handler is available in the current try block. If a correct exception handler is available in block 140, then in block 150, the correct exception handler in selected. The exception is processed in the correct exception handler in block 152.
Returning to block 140, if a correct exception handler is not available, then the process continues in block 120 as described below.
Often try blocks are nested i.e. a first try block is fully contained within a second try block and the second try block could also be fully contained within yet a third try block and so forth. When the try blocks are nested, as described above, the second try block is described as having a higher level then the first try block. The third try block has a higher level than both the first and the second try blocks.
Returning to block 108, if the current try block does not include any exception handlers, then the process continues at block 120. In block 120 if there is a next higher level try block, then in block 122, the next higher level try block is designated as the current try block and the process repeats beginning at block 106.
If in block 120, there is not a next higher level try block, then in block 124 the data structure of the entire code is examined to find the exception handlers in the current method. In block 126 the process shifts to the exception handlers in the current method to process the exception. In block 128, the exception handlers in the current method are examined to determine if a correct exception handler is available in the current method. If a correct exception handler is available in block 128, then the process continues in block 150 as described above.
If a correct exception handler is not available in the current method in block 128, then the process continues in block 130. Often one method (a caller method) will call another method (a callee method) and therefore the exception handlers the caller method may be used to process the exception from the callee method. In block 130, the code is examined to determine if there is a subsequent method that called the current method. If there is a subsequent method that called the current method, then the subsequent method is designated as the current method in block 132 and the process repeats at block 124 above. If there is not a subsequent method that called the current method, then the execution stops in block 134 and an error results because the exception cannot be processed.